Summary

Adds support for hosting Bulwark under a sub-path (e.g. /webmail) by reading basePath from the NEXT_PUBLIC_BASE_PATH env var at build time.

Motivation

When Bulwark is proxied under a sub-path via reverse proxy (nginx, Traefik, etc.), Next.js's basePath config is required so the server generates correct URLs. However, basePath does not automatically prefix client-side fetch() calls — only navigation. This causes all API requests from the browser to target the wrong URL (/api/... instead of /webmail/api/...), breaking authentication, settings, calendars, plugins, etc.

This is documented Next.js behavior but surprising, and the fix is simple: wrap API URLs in a helper that reads the basePath.

Changes

• next.config.ts: conditionally set basePath from process.env.NEXT_PUBLIC_BASE_PATH; expose the value as a public env var so the client can read it
• lib/api-path.ts: new helper exporting apiPath(path) that prepends basePath (no-op when empty); returns input unchanged if already prefixed
• lib/api-path.test.ts: unit tests covering empty/unset basePath, happy path, and idempotency
• hooks/, lib/, stores/, components/, app/: wrap 98 fetch('/api/...') calls in apiPath() across 26 files

Server-side route handlers (app/api/*/route.ts) were not modified — basePath does not apply to internal routing.

Usage

NEXT_PUBLIC_BASE_PATH=/webmail npm run build

When NEXT_PUBLIC_BASE_PATH is empty or unset, behavior is unchanged.

Test plan

• Unit tests pass (vitest lib/api-path.test.ts)
• Reviewer: verify build succeeds with and without NEXT_PUBLIC_BASE_PATH set
• Reviewer: smoke-test login flow under /webmail with NEXT_PUBLIC_BASE_PATH=/webmail

Notes

• This replaces the need for downstream projects (e.g. Jabali Panel) to maintain sed-based patches against Bulwark sources.
• No runtime dependencies added.
• Bundle size impact: negligible (tiny helper function).